home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 13 / QRZ Ham Radio Callsign Database - Volume 13.iso / unix / src / qrztech.txt < prev    next >
Text File  |  1996-06-23  |  7KB  |  161 lines
  1.  
  2. The QRZ! Ham Radio CDROM 
  3. Callsign Database Technical Specification         Rev B May 1995 
  4.  
  5.  
  6. Note: the following information is provided for those who wish to
  7. access the callsign database information without the use of the QRZ!
  8. software.  Users of the QRZ! Ham Radio CDROM who wish to write their
  9. own callsign database search and retrieval software are encouraged to
  10. do so.  We welcome user contributed shareware programs for future
  11. versions of the QRZ! Ham Radio CDROM.
  12.  
  13.  
  14. PC VERSIONS
  15.  
  16. For the PC, there are two versions of the QRZ! software, one for DOS
  17. and one for Windows 3.1.  Both versions use the same copy of the
  18. database and the same primary search and retrieval methods.
  19.  
  20. The QRZ callsign database indexing and retrieval method was designed
  21. and optimized for CDROM use.  The primary goal was to provide fast
  22. access for searches in light of the fact that typical CDROM seek times
  23. are somewhat slow compared to hard disk.  The algorithm described below
  24. implements a methodology which requires only one  CDROM  disc seek per
  25. lookup.
  26.  
  27. The QRZ callsign database is composed of four copies of the data, each
  28. sorted by a different criteria.  One copy is sorted by callsign, one by
  29. last name, one by city-state and one by zip code.  Note that only the
  30. callsign database contains the foreign (DX) records.  We would have
  31. liked to sort the DX callsigns by name and by city, etc., but could not
  32. since there is no universal address format.  Therefore, DX callsigns
  33. can be fetched by callsign only.
  34.  
  35.  
  36. Each datafile has its own corresponding index file.  An index file
  37. contains selected keys from the corresponding database sampled at
  38. regular intervals.  The key sampling interval is stored in the index
  39. header as bytesperkey, as shown in the structure definition below.
  40.  
  41.  
  42. /*
  43. **     Index Header Block Definition (Version 2)
  44. **     (applies to all QRZ CDROMS from Version 2 onward) 
  45. **
  46. **     This block is located at the start of each index
  47. */
  48. typedef struct {
  49.   char  dataname[16];    /* Name of the data file            */
  50.   char  bytesperkey[8];  /* Data Bytes per Index Item        */
  51.   char  numkeys[8];      /* Number of items in this index    */
  52.   char  keylen[8];       /* Length of each key item in bytes */
  53.   char  version[8];      /* Database Version ID              */
  54. } index_header;
  55.  
  56.  
  57. Index Usage
  58.  
  59. The name index is set to a maximum of 16 characters with longer names
  60. being truncated.   Names are stored in last-first format with a space
  61. between the names.  The city/state index uses 12 characters per entry,
  62. the callsign index 6 characters and the zip code index 5 characters.
  63.  
  64. The data which follows the header is simply a long list of single field
  65. records. The records are tightly packed on 'bytesperkey' boundaries
  66. without separators.  There is no guarantee of a null terminator on any
  67. index record entry.
  68.  
  69. When the program qrz.exe is run it first searches for a drive
  70. containing the base directory \CALLBK .  Next, it loads all four index
  71. files (callbkc.idx, callbkn.idx, callbks.idx and callbkz.idx) into
  72. tables in memory.  These tables were kept small so as not to place an
  73. undue RAM requirement on the user's system.
  74.  
  75. Next, when a user specifies a field and key to search, the program
  76. searches the relevant index table and returns the closest match lower
  77. (or equal to) the supplied key.  The table position of this key is then
  78. taken and multiplied by the 'bytesperkey' value to arrive at a database
  79. file offset.  This offset is then used to perform the first and only
  80. seek into the database.  Once on position within the file, a sequential
  81. search is performed to return the match.  The search terminates at the
  82. next index key value if the field is not found.
  83.  
  84. The database files all have the same format.  The records each consist
  85. of comma separated fields which end with a single newline '\n'  (ASCII
  86. 0xa) character.  Blank fields are simply stored as a comma.  Every
  87. record has the same number of commas in it.  Actual comma's in the data
  88. field are stored as a semi-colon ';' which should be replaced by a
  89. comma in the user's output formatting routine.
  90.  
  91.  
  92. Example:
  93.  
  94. AA7BQ ,LLOYD,,FRED L,,53340,90009,00009,8215 E WOOD DR,SCOTTSDALE,AZ,
  95. 85260,E,KJ6RK,A
  96.  
  97. /*
  98. **    Standard Record Field Offsets
  99. */
  100. #define CALL            0       AA7BQ
  101. #define LNAME           1       LLOYD
  102. #define JR              2       (not used) ***
  103. #define FNAME           3       FRED L
  104. #define MI              4       (not used) ***
  105. #define DOB             5       53340
  106. #define EFDATE          6       90009
  107. #define EXPDATE         7       00009
  108. #define MAIL_STR        8       8215 E. Wood DR
  109. #define MAIL_CITY       9       SCOTTSDALE
  110. #define MAIL_ST         10      AZ
  111. #define MAIL_ZIP        11      85260 
  112. #define CLASS           12      E
  113. #define P_CALL          13      KJ6RK 
  114. #define P_CLASS         14      A 
  115.  
  116. *** The fields JR and MI were obsoleted by the FCC in July 1994.
  117.  
  118. The callsign fields are arranged in a strict "ccdccc" columnar format
  119. where 'c' represents a letter and 'd' a digit. Callsigns which do not
  120. conform to the "ccdccc" format are space filled in the relevant
  121. positions.  This field is rearranged to the proper layout by the user
  122. program's output formatting routines.
  123.  
  124. All dates are stored in 5 character Julian format, e.g. 93003 equals
  125. January 3, 1993.  Dates before 1900 or after year 2000 must be
  126. determined by their context usage.  In other words, if the resultant
  127. age does not make sense, then it's wrong.  For example, all licenses
  128. expire in the future so 02 is 2002.  Birthdays are more difficult
  129. but most can be determined to be greater than 10 years old.  This is
  130. not a perfect method, but it does yield satisfactory results.
  131.  
  132. Some folks may notice that the database no longer contains station
  133. location information.  This information is no longer supplied nor
  134. available from the FCC since it is no longer a part of their record
  135. keeping (See the May 1993 QST for more info).
  136.  
  137.  
  138. Cross Reference Information
  139.  
  140. Callsigns in the database are now cross-referenced to both the current
  141. and the previous call sign for each entry in which they are available.
  142. A cross reference record takes the form of 'old,new' with no other
  143. information in the record.  A record can be identified as a cross
  144. reference either one of two ways:
  145.  
  146.     First, if the record length is less than 15 characters, then
  147.     it is a cross reference record.
  148.  
  149.     Secondly, if the record contains only one comma "," , then
  150.     it is a cross reference record.
  151.  
  152. It is not necessary to test for both cases, either will do.
  153.  
  154. When a cross reference record is encountered, you must fetch the second
  155. field and restart the search to return the primary reference.
  156.  
  157. -------------------------------------------------------------------
  158.  
  159. Fred Lloyd, AA7BQ   05/24/95
  160.  
  161.